Converged networks support several protocols, such as SIP, H.323, and H.248, which provide session control, although SIP is now emerging as the predominant protocol because it is easy to use and offers many useful features.
Session Initiation Protocol (SIP) is an application-layer signalling protocol for creating, modifying, and terminating sessions with one or more participants. These sessions can include Internet telephone calls (e.g. VoIP), multimedia distribution, and multimedia conferences.
SIP invitations used to create sessions carry session descriptions that enable participants to agree on a set of compatible media types. SIP uses elements called proxy servers to route requests to the user's current location, to authenticate and authorize users for services, to implement provider call-routing policies, and to provide various features to users. SIP also provides a registration function that enables users to upload their current locations for use by proxy servers.
The first proposed standard version of SIP (SIP Version 2.0) was defined in RFC 2543, and this protocol was further clarified in RFC 3261, both of which are hereby incorporated by reference.
When using SIP, several messages are exchanged end-to-end (e2e) or hop-by-hop (where a “hop” connects two SIP-processing network elements). The time required for a system to establish a connection between two endpoints to set up a communication path is known as the “session setup time”. A minimal session setup time thus enhances user satisfaction, particularly for a service such as Internet telephony where customers (who are used to quick call setups times in PSTN and wireless) expect equally quick session setup time for VoIP.
SIP messages carry a SIP-based header and SDP-based session description. The header contains self-explanatory fields such as Message type, Access network, From, To, Via, Max-forwards, Call-ID, Required QoS preconditions, supported messages, content type and content, length, etc. The messages include a description based on SDP about media properties such as media type (e.g. voice, video, or text), bandwidth requirements, IP address, codecs (COder/DECoders), direction of flow, etc. For example, an INVITE message includes all the media requirements based on the capability of that particular end terminal. For example, the INVITE message can include a QoS requirement (e2e or segmented, i.e. only in the access network).
A typical end-to-end connection in a converged network involves end terminals (e.g. handsets, PDA's, computers, etc.), an access network (which can be wire-line, e.g. cable, DSL, LAN, or wireless, e.g. 3GPP/2, GPRS), a packet transport network (which can be public, private or carrier) and session control elements (e.g. softswitches, gateways, CSCF nodes, etc.).
The session control traffic is directed from one end user to the other through all these elements with some segments such as access and transport being shared with the media traffic. As negotiation options increase, so does the number of messages exchanged between two user terminals or equipment to set up a session. This may result in long session setup latencies and reduced user satisfaction. In legacy telephony, only three messages are used to set up a connection between two users with call setup latency in the range of a few milliseconds to a few seconds over dedicated or prioritized connections. That would be very difficult to achieve with present-day SIP due to the number of messages required to set up a session, particularly with a low-bandwidth access and links. This is particularly problematic for wireless access where bandwidth resources tend to be limited.
FIG. 1 schematically illustrates a typical SIP-based session setup in accordance with the prior art. In this session setup, a SIP pre-condition provides that the end user is not alerted until the resource reservation is completed on both ingress and egress networks. As shown in FIG. 1, a total of 12 messages are exchanged e2e for a successful setup with 4 messages of these 12 messages being used for resource reservation, namely PRACK (Counteroffer), 200 OK (PRACK), UPDATE (reservation complete), and 200 OK (UPDATE).
The offer/answer exchanges in SIP can be made reliable by using PRACK messages, as is described in RFC 3262. Reliability also ensures interoperability with the PSTN. The PRACK reliability mechanism mirrors the reliability mechanisms for 2xx final responses to INVITE. Those requests are transmitted periodically by the Transaction User (TU) until a separate transaction, ACK, is received that indicates reception of the 2xx by the user-agent client (UAC). The reliability for the 2xx responses to INVITE and ACK messages are end-to-end. In order to achieve reliability for provisional responses, reliable provisional responses are retransmitted by the TU with an exponential backoff and cease when a PRACK message is received. The PRACK request is similar to ACK, but for provisional responses. However, PRACK is a normal SIP message and, as such, its own reliability is ensured hop-by-hop through each stateful proxy. Unlike ACK, PRACK has its own response. If this were not the case, the PRACK Message could not traverse proxy servers compliant with RFC 2543 and RFC 3261.
FIG. 2 schematically illustrates an alternative SIP-based session setup in accordance with the prior art. This alternative is currently being proposed in the standards as a more efficient session setup. The number of messages required to set up the session is reduced by four to a total of only 8 messages. As shown in FIG. 2, however, this alternative setup requires that resources be reserved at the caller before the INVITE message is sent, thus potentially blocking any other incoming calls that might arrive during the session setup. Bandwidth is therefore potentially wasted because the callee might not be available while other calls are being blocked from reaching the caller.
Thus, it remains highly desirable to provide a method that expedites resource negotiation in SIP.